home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1109.txt < prev    next >
Text File  |  1994-08-01  |  20KB  |  451 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            V. Cerf
  8. Request for Comments:  1109                                          NRI
  9.                                                              August 1989
  10.  
  11.  
  12.       Report of the Second Ad Hoc Network Management Review Group
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This RFC reports an official Internet Activities Board (IAB) policy
  19.    position on the treatment of Network Management in the Internet. This
  20.    RFC presents the results and recommendations of the second Ad Hoc
  21.    Network Management Review on June 12, 1989.  The results of the first
  22.    such meeting were reported in RFC 1052 [1].  This report was approved
  23.    and its recommendations adopted by the IAB as assembled on July 11-
  24.    13, 1989.  Distribution of this memo is unlimited.
  25.  
  26. INTRODUCTION
  27.  
  28.    On February 29, 1988, an Ad Hoc Network Management Review Group was
  29.    convened to consider the state of network management technology for
  30.    the Internet and to make recommendations to the Internet Activities
  31.    Board as to network management policy.  The outcome of that meeting
  32.    was summarized in RFC 1052 and essentially established a framework in
  33.    which two network management protocols now known respectively as
  34.    Simple Network Management Protocol (SNMP) and Common Management
  35.    Information Protocol on TCP (CMOT) were selected for further work.
  36.    Subsequently, both SNMP [6] and CMOT [5] were advanced to Draft-
  37.    Standard/Recommended status for use in the Internet [SNMP: RFC 1098,
  38.    CMOT: RFC 1095].
  39.  
  40.    Simultaneously, it was agreed to establish a working group to
  41.    coordinate the definition and specification of managed objects to be
  42.    used in common with either protocol.  In addition, it was agreed to
  43.    use the then current ISO Structure of Management Information (SMI)
  44.    specification as a reference standard to guide the naming and
  45.    abstraction conventions that would be followed in constructing the
  46.    common Internet Management Information Base (MIB).  The Internet
  47.    versions of SMI and MIB were specified in RFC 1065 [2] and RFC 1066
  48.    [3] respectively.
  49.  
  50.    In the intervening fifteen months, considerable progress has been
  51.    made in the specification of a common Management Information Base and
  52.    in the implementation, deployment and use of network management tools
  53.    in the Internet.
  54.  
  55.  
  56.  
  57.  
  58. Cerf                                                            [Page 1]
  59.  
  60. RFC 1109                  Internet Management                August 1989
  61.  
  62.  
  63.    The current public subtree of the Internet MIB contains roughly 100
  64.    variables (i.e., managed objects) agreed by the SNMP and CMOT working
  65.    groups as mandatory for Internet network management.  The June 12,
  66.    1989 meeting which this document reports was convened to review the
  67.    progress to date, to determine whether actions were needed to foster
  68.    further evolution of network management tools and to recommend
  69.    specific actions in this area to the IAB.
  70.  
  71. SNMP STATUS
  72.  
  73.    Immediately after the meeting reported in RFC 1052, a group was
  74.    convened to make extensions and changes to the predecessor to SNMP:
  75.    Simple Gateway Monitoring Protocol.  A "connectathon" was held at
  76.    NYSERNet, an RFC published, and demonstrations of network management
  77.    tools using SNMP were offered in the Fall at Interop 88 [a conference
  78.    and show presented by Advanced Computing Environments (ACE)].  The
  79.    protocol is in use in a number of networks within the Internet as
  80.    well as in private packet networks internationally.  A number of
  81.    vendor implementations are in the field (e.g., cisco Systems,
  82.    Proteon, The Wollongong Group), vendor independent reference
  83.    implementations (e.g., NYSERNet, Case and Key in Tennessee) along
  84.    with some freely available versions (e.g., MIT, CMU).
  85.  
  86.    It is important to note that while the common Internet Management
  87.    Information Base has roughly 100 variables, a typical SNMP monitoring
  88.    system may support anywhere from 100 to 200 ADDITIONAL objects which
  89.    have been defined in private or experimental MIB space.  Many of
  90.    these are device or protocol dependent variables.
  91.  
  92.    Scaling to include larger numbers of monitored objects and subsystems
  93.    remains a challenge.  It was observed that fault monitoring was
  94.    easier to scale than performance and configuration monitoring, since
  95.    the former may operate on an exception basis while the latter is more
  96.    likely to require periodic reporting.
  97.  
  98. CMOT STATUS
  99.  
  100.    RFC 1095 (CMOT) was recently published and built upon experience
  101.    gained earlier with prototype implementations demonstrated at Interop
  102.    88 in the Fall of that year.  The present specification for CMOT is
  103.    based on the ISO Draft International Standard version of Common
  104.    Management Information Protocol (CMIP).  The CMIP is being moved to
  105.    International Standard status, though the precise timing is not
  106.    perfectly clear.  It will happen late in 1989 or perhaps in the first
  107.    quarter of 1990.  Some changes will be made to correct known errors
  108.    and the CMIP document itself will probably be restructured.
  109.  
  110.    During this discussion, it was pointed out that there is much to
  111.  
  112.  
  113.  
  114. Cerf                                                            [Page 2]
  115.  
  116. RFC 1109                  Internet Management                August 1989
  117.  
  118.  
  119.    network management which is not addressed by either the CMOT or the
  120.    SNMP specifications: for example, down loading of software,
  121.    configuration management and user access control.  Authentication of
  122.    the source of network management commands and responses is another
  123.    area important to providers and users of network management tools.
  124.  
  125.    The National Institute for Standards and Technology (NIST) is
  126.    sponsoring the development of implementors' agreements on the
  127.    functional behavior of network management tools including, inter
  128.    alia, logging, event reporting, error reporting, structured object
  129.    management, and alarm reporting.
  130.  
  131.    Although at the time of the meeting, there were no publicly available
  132.    implementations of CMOT reported, developments were reportedly
  133.    planned by a number of vendors both in the form of agents and network
  134.    management tools.  The University of Wisconsin plans to demonstrate
  135.    CMOT using the ISODE software at Interop 89 [(tm) ACE] in September
  136.    1989.
  137.  
  138. MIB AND SMI STATUS
  139.  
  140.    In the Fall of 1988, two RFCs were published (1065 and 1066) to
  141.    specify the Structure of Management Information (SMI) and the initial
  142.    Internet Management Information Base (MIB) respectively.  There were
  143.    some challenges in crafting this set of commonly agreed variables; in
  144.    the end, roughly 100 were agreed and defined as mandatory for
  145.    Internet management.
  146.  
  147.    It was recognized in this process that the definition of the layer
  148.    BELOW IP was a difficult task.  IP is sufficiently simple and general
  149.    that it has been moved in encapsulated form over many media including
  150.    the MAC level of various local nets, X.25 packet level, serial line
  151.    protocols, multiplexors, tunnels and, it is rumored, tin cans and
  152.    string.
  153.  
  154.    At the Transport level, specifically for TCP, it was observed that
  155.    information about the transient status of connections was potentially
  156.    inaccessible to the network management tools since the loss of a TCP
  157.    connection typically meant loss of its Transmission Control Block
  158.    (status block) just when you wanted to look back into the history of
  159.    its state.  Countervailing this observation was evidence that looking
  160.    at TCBs with network management tools yielded far more insight into
  161.    the transient behavior of TCP than looking at aggregated network
  162.    statistics.
  163.  
  164.    It was clear from the discussion that there is strong interest in
  165.    extending the variables accessible via network management tools.
  166.    Adding new devices, new higher level protocols and the ability to
  167.  
  168.  
  169.  
  170. Cerf                                                            [Page 3]
  171.  
  172. RFC 1109                  Internet Management                August 1989
  173.  
  174.  
  175.    manipulate configuration information were high on the list of
  176.    desirable extensions, although several participants felt that this
  177.    desire needed some moderation.
  178.  
  179.    A vital, but unsettled research area has to do with relationships
  180.    among groups of monitored variables.  A particular implementation may
  181.    have IP operating atop X.25.  The problem is to be able to make
  182.    queries about the condition of monitored variables so that those for
  183.    the IP level can be correlated with those for a lower layer, for
  184.    instance.  This notion of relationship is especially important as
  185.    network devices (including hosts) begin to sport multiple network
  186.    connections and multiple protocol suites operating in parallel.  Just
  187.    how the dynamics of such relationships are to be specified, defined
  188.    and instantiated is the research question.  What sort of SMI is
  189.    appropriate? What generic structure is needed for the management
  190.    objects?
  191.  
  192.    Another difficult topic has to do with version numbers for SMI.  The
  193.    issue is "which version of MIB is instantiated in this monitored
  194.    system?"  As consideration of extensions to the currently agreed SMI
  195.    were contemplated during the last fifteen months, it became apparent
  196.    that the question of versions was central.
  197.  
  198.    Not far behind was the question of functionality of the underlying
  199.    support protocols (SNMP and CMOT).  The RFC 1052 recommendation was
  200.    to tightly link the MIB/SMI, keeping only one such definition for
  201.    both protocols.  In theory, this plan would make it easier to move
  202.    from one protocol base to another.  In practice, it appears to have
  203.    stifled exploration of new variable and function definitions in
  204.    operating network environments.  This point needs to be underscored:
  205.    it is essential for the Internet community to have the freedom to
  206.    explore the utility of the OSI offerings while, at the same time,
  207.    having the freedom to respond to operational needs through the
  208.    definition and use of new MIB variables and SMI features.
  209.  
  210.    Yet another area still needing development has to do with the
  211.    archiving of operational data collected by means of a network
  212.    management tool.  The ISO Common Management Information Service
  213.    (CMIS) specifications do not treat this matter.
  214.  
  215.    Finally, it was pointed out that registration of managed objects and
  216.    their definitions was still an open area although the NIST has
  217.    apparently made progress through its Network Management Special
  218.    Interest Group (NMSIG) in planning for cataloging of defined
  219.    management information objects.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Cerf                                                            [Page 4]
  227.  
  228. RFC 1109                  Internet Management                August 1989
  229.  
  230.  
  231. APPLICATION PROGRAMMING INTERFACE (API)
  232.  
  233.    It was generally agreed that the actual network management tools
  234.    available to operators, rather than the specifics of the protocols
  235.    supporting the tools, would be the determining factor in the
  236.    effectiveness of any Internet network management system.  A brief
  237.    report was offered and discussion ensued on the possibility of
  238.    creating a common application programming interface that could be
  239.    used independent of the specific protocol (CMOT, SNMP, CMIP or
  240.    proprietary) used to transport queries and commands.
  241.  
  242.    It was acknowledged that the present service interfaces of both SNMP
  243.    and CMIS have limitations (e.g., neither has any sense of time other
  244.    than "now"; this makes it impossible to express queries for
  245.    historical information, or to issue command requests of the form: Do
  246.    X at device Y, beginning in 30 minutes).  These limitations hinder
  247.    both SNMP and CMOT from directly offering a comprehensive API for
  248.    network management applications.
  249.  
  250.    Although some positive sentiment was expressed for defining a kind of
  251.    "super SMI" metalanguage to aid in the the definition of a general
  252.    API, it was not clear whether the current crop of supporting
  253.    protocols had sufficient semantic commonality to be used in this way.
  254.    The matter remains open for investigation.
  255.  
  256. NIST ACTIVITIES
  257.  
  258.    The Ad Hoc Review had the benefit of representatives from NIST who
  259.    are active in the network management area.  It was reported that the
  260.    major focus at present is at layers 3 and 4 where objects are being
  261.    defined in accordance with "templates" provided by ISO's SC21.  IEEE
  262.    802 is also pursuing the definition of MIB objects, though not with
  263.    the benefit of the same templates now in use by the NIST NMSIG.  The
  264.    layers above transport are just beginning to receive attention.
  265.  
  266.    It was observed that the Internet SMI is not quite a subset of the
  267.    ISO CMIS SMI.  The Internet variable naming conventions are a little
  268.    different and some functionality may vary.  There was some
  269.    uncertainty about the treatment of gauges in the Internet SMI and the
  270.    corresponding OSI SMI.  [L. Steinberg reported, subsequent to the
  271.    meeting, that gauges latch and counters roll over in the OSI SMI, as
  272.    they appear to do in the Internet SMI - VGC].
  273.  
  274.    The general sense of this portion of the discussion was that a
  275.    considerable amount of activity is underway with the sponsorship of
  276.    NIST and that this work is relevant to the Internet community,
  277.    particularly as the time approaches in which coexistence of the OSI
  278.    protocol suite with the existing Internet protocols is the norm.
  279.  
  280.  
  281.  
  282. Cerf                                                            [Page 5]
  283.  
  284. RFC 1109                  Internet Management                August 1989
  285.  
  286.  
  287. CONCLUSIONS AND RECOMMENDATIONS
  288.  
  289.    The assembled attendees came to the conclusions enumerated below and
  290.    recommends to the IAB that actions be taken which are consistent with
  291.    these conclusions:
  292.  
  293.       1. The Internet will exist in a pluralistic protocol stack
  294.          environment and the need to coexist will persist.
  295.  
  296.       2. Expansion of the common MIB has been impeded by an inability to
  297.          agree on a common, extended SMI.
  298.  
  299.       3. The Internet community must not ignore the work of other groups
  300.          in the network management area, while at the same time, coping
  301.          with the current operational needs of the Internet (and
  302.          internet) communities.
  303.  
  304.       4. Until we can gain operational experience with OSI network
  305.          management tools (e.g., with CMIP on TCP or on OSI), we cannot
  306.          specify a plan for coexistence with and transition to use of
  307.          the OSI-based protocols in the Internet.
  308.  
  309.    Therefore:
  310.  
  311.       (a) We want to foster an environment for real CMOT/CMIP use.
  312.  
  313.       (b) We should take action as needed to extend SNMP for operational
  314.           reasons.
  315.  
  316.       (c) We must preserve the utility of the first agreed common MIB
  317.           (RFC 1066).
  318.  
  319.       (d) We should develop, separately, experimental and enterprise MIB
  320.           variables and seek opportunity for placing these in the common
  321.           MIB.
  322.  
  323.       (e) In a coexisting environment, we will need to access the same
  324.           set of variables (e.g., in a given gateway or router) by means
  325.           of more than one protocol (e.g., SNMP, CMIP/TCP, CMIP/CLNP,
  326.           etc.).
  327.  
  328.    It is recommended to the IAB that the network management efforts
  329.    using SNMP and CMOT be allowed independently to explore new variables
  330.    and potentially non-overlapping SMI definitions for the next 12
  331.    months so as to foster operational deployment and experience with
  332.    these network management tools.  In essence, it is recommended that
  333.    the binding of SNMP and CMOT to a common MIB/SMI be relaxed for this
  334.    period of exploration.  Variables which are NOT supportable in common
  335.  
  336.  
  337.  
  338. Cerf                                                            [Page 6]
  339.  
  340. RFC 1109                  Internet Management                August 1989
  341.  
  342.  
  343.    by both protocols should be defined in the experimental or private
  344.    parts of the MIB definition space.  Obviously, care should be taken
  345.    to achieve agreement within each respective working group on any
  346.    variables added to the distinct SNMP and CMOT experimental spaces.
  347.  
  348.    Specifically, the CMOT working group should extend its MIB and SMI
  349.    definitions in the direction of the OSI/NIST specifications so as to
  350.    bring CMOT into closer alignment with the OSI CMIS design.
  351.  
  352.    During this period of experimentation, it is strongly recommended
  353.    that the IAB seek opportunities to encourage the introduction of
  354.    Internet elements which use the OSI protocols into the Internet
  355.    environment.  Such OSI-based elements offer an opportunity to obtain
  356.    operational experience with monitoring and management support by way
  357.    of the CMIP and CMOT protocols.  It is anticipated that network
  358.    management systems based on the OSI Common Management Information
  359.    Service (CMIS) will be developed which use CMIP or CMOT, as
  360.    appropriate, to manage various elements in the Internet.
  361.  
  362.    It is also recommended that the IAB engage in an active liaison
  363.    effort with the NIST, focusing especially on the question of
  364.    coexistence of the Internet protocols with OSI protocols.  If at all
  365.    possible, joint experimental or test-bed efforts should be initiated
  366.    to identify means for supporting this coexistence.
  367.  
  368.    As necessary, the Internet Engineering Task Force should be directed
  369.    to restructure its network management efforts both to support the
  370.    need for MIB/SMI exploration by the SNMP and CMOT groups and to
  371.    strengthen links between the IETF efforts and those of NIST.
  372.  
  373.    Finally, it is recommended that the Ad Hoc Review Group be reconvened
  374.    at 6 month intervals to review status and to determine whether
  375.    opportunities for expanding the common MIB/SMI are available.
  376.  
  377. REFERENCES
  378.  
  379.    1.  Cerf, V., "IAB Recommendations for the Development of Internet
  380.        Network Management Standards", RFC 1052, NRI, April 1988.
  381.  
  382.    2.  Rose, M., and K. McCloghrie, "Structure and Identification of
  383.        Management Information for TCP/IP-based internets", RFC 1065,
  384.        TWG, August 1988.
  385.  
  386.    3.  McCloghrie, K., and M. Rose, "Management Information Base for
  387.        Network Management of TCP/IP-based internets", RFC 1066, TWG,
  388.        August 1988.
  389.  
  390.    4.  Schoffstall, M., C. Davin, M. Fedor, and J. Case, "SNMP over
  391.  
  392.  
  393.  
  394. Cerf                                                            [Page 7]
  395.  
  396. RFC 1109                  Internet Management                August 1989
  397.  
  398.  
  399.        Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT
  400.        Laboratory for Computer Science, NYSERNet, Inc., and University
  401.        of Tennessee at Knoxville, February 1989.
  402.  
  403.    5.  Warrier, U., and L. Besaw, "Common  Management Information
  404.        Services and Protocol over TCP/IP (CMOT)", RFC 1095, Unisys
  405.        Corporation, and Hewlett-Packard, April 1989.
  406.  
  407.    6.  Case, J., M. Fedor, M. Schoffstall, and C. Davin, "Simple Network
  408.        Management Protocol (SNMP)", RFC 1098, University of Tennessee at
  409.        Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, and
  410.        MIT Laboratory for Computer Science, April 1989.
  411.  
  412. Appendix A - Ad Hoc Net Management Review Attendance List
  413.  
  414.    Amatzia Ben-Artzi   3Com
  415.    Paul Brusil         MITRE
  416.    John Burruss        Wellfleet Communications
  417.    Jeff Case           University of Tennessee at Knoxville
  418.    Vint Cerf           National Research Initiatives
  419.    Ralph Droms         Bucknell University (on sabbatical at NRI)
  420.    Mark Fedor          NYSERNet
  421.    Phill Gross         National Research Initiatives
  422.    Lee LaBarre         MITRE
  423.    Bruce Laird         Bolt Beranek and Newman
  424.    Gary Malkin         Proteon
  425.    Keith McCloghrie    Wollongong
  426.    Craig Partridge     Bolt Beranek and Newman
  427.    Marshall Rose       NYSERNet
  428.    Greg Satz           cisco Systems
  429.    Marty Schoffstall   NYSERNet
  430.    Louis Steinberg     IBM
  431.    Dan Stokesberry     NIST
  432.    Unni Warrier        Netlabs
  433.  
  434. Author's Address
  435.  
  436.    Vinton G. Cerf
  437.    Corporation for National Research Initiatives
  438.    1895 Preston White Drive, Suite 100
  439.    Reston, VA 22091
  440.  
  441.    Phone: (703) 620-8990
  442.  
  443.    EMail: CERF@A.ISI.EDU
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Cerf                                                            [Page 8]
  451.